1. Field of the Invention
The invention relates generally to software development process. More specifically, the invention relates to a method and system for test-running and debugging web applications.
2. Background Art
A web application is a web site where users can access the information they need and change the state of application logic on a server through a set of web pages. Web application development is usually centered around tools and technologies. A web application centered around the Java™ technology may comprise the following: JSP™ pages and Java™ servlets that handle HTTP requests and generate dynamic content, server-side beans that encapsulate application behavior and state, static HTML files, DHTML files, image files, sound files, and libraries with additional Java™ components, such as client-side Java™ applets and any Java™ class files used by the other Java™ components. The J2EE™ specification describes a standard for how to organize such files into web modules, including describing how they are accessed. Web modules could be developed in an IDE, such as sold under the trade name Forte™ for Java™ by Sun Microsystems, Inc.
The task of debugging web applications such as described above is in some ways very different from standalone executables. A common approach to identifying bugs in standalone programs is source level debugging. Source level debugging essentially involves following the execution of a program by stepping through the source code line by line. At each step of the debugging process, the program's internal variables are accessed and examined to isolate the source of the bug. While this approach is useful for debugging standalone programs, it is often too fine-grained for web applications for two reasons. One of the reasons is that the behavior of the components that make up a web application, at least the components that handle the HTTP transactions, are typically very simple in comparison to the components of the standalone program. The other reason is that the components of the web application are managed by the web server, not by the web application itself. This means that data flow between the components is managed at the level of the web server.
In the Java™-centered web application described above, the components that enable dynamic content generation include the JSP™ pages and Java™ servlets. The following is a listing of a sample JSP™ page that sets a new attribute and generates a response page which displays the attribute the user is trying to set and the attributes that are currently set.
Sample Listing of a JSP ™ Page<%@page contentType =“text/html”%><html><head> <title>Output Page</title> </head><body><h1>Output page</h1><p>You added the following attribute to the session:<table><tr> <td> <b>Attribute:</b> </td><td> <%=request.getParameter(“att”)%> </td><td> <b>Value</b> </td><td> <%=request.getParameter(“val”)%> </td></tr> </table><%session.Attribute ((String) request.getParameter(“att”),request.getParameter(“val”));%><p>Current attributes in the session:<table><tr> <td> <b>Attribute</b> </td> <td> <b>Name</b> </td> </tr><%java.util.Enumeration e = session.getAttributeNames ( );while e.hasMoreElements ( )) {String name = (String)e.nextElement( );String value = (String)session.getAttribute(name);out.println(“<tr> <td>” + name + “</td> <td>” + value + “</td> </tr>”);}%></table></body></html>
The code excerpt above is fairly representative of the level of complexity in JSP™ pages. A JSP™ page can involve complex processing, but the code that performs the complex processing is typically encapsulated in a bean or in a JSP™ tag, leaving the source of the page itself relatively simple. In many cases, bugs in JSP™ pages can be easily identified by visual inspection of the code. The same is true for servlets. In practice, many of the bugs in JSP™ pages and servlets, or for that matter any dynamic page generation components, arise because of incorrect data flow between the components of the web application. For this reason, source level debugging is too fine grained a process as a first option for debugging JSP™ pages and servlets. If the user has access to the parameter values and other data used by the JSP™ page or servlet, they can often identify the source of the problem much quicker than if they have to go through the overhead of starting a debugger and stepping through the code.
The data passed into the JSP™ page is not easily available to the developer. The data comes from different sources such as the parameters passed in with the HTTP request, cookies, session variables, and HTTP headers. These sources are all managed at the level of the HTTP server as opposed to by the JSP™ page itself, and the HTTP server usually does not provide an easy way of tracking the data. While HTTP request parameters may be shown in the browser's location window for HTTP “get” requests, nothing is shown for HTTP “post” requests, and cookies and session variables are typically not logged by either the server or the browser. Likewise, there is usually no easy way to display the HTTP headers sent by the client.
In order to be able to test-run and debug the web application efficiently, a mechanism is needed which will allow data flow between the components of the web application to be monitored. If the data flow between the components of the web application can be followed, then the component not behaving correctly can be identified. Even where the problem is not incorrect data flow, monitoring data flow can help quickly determine where the problem arises. Once the component during whose execution the problem arises has been identified, the source of the bug can be isolated. The bug may be in the JSP™ page or servlet itself or in a component which the JSP™ page or servlet invokes. As pointed out above, bugs in the JSP™ page or servlet are often obvious from code inspection. Source level debugging may be needed if the bugs are in components invoked by the JSP™ page or servlet.